Automated personalized out-of-the-box and ongoing in-application settings

ABSTRACT

Systems, methods, and computer-readable storage media are provided for automating personalized out-of-the-box and ongoing in-application settings. A triggering event is detected for an exchange of information between an information service and one or more application or service. A trust level and domain of information of the one or more application or service is determined. Based on the trust level and domain of information, information to be shared with the one or more application or service is identified and the identified information is shared. The information to be shared can be all of the requested information, some of the requested information, or none of the requested information.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No.62/474,548, entitled “Automated Personalized Out-Of-The-Box and OngoingIn-Application Settings,” filed Mar. 21, 2017, which is hereby expresslyincorporated by reference in its entirety.

BACKGROUND

The number of computer applications available to a user continues togrow at a rapid pace. For many applications, a user must enter personalinformation and preferences to use the application and/or make theapplication useful. However, with so many options available to users, auser may have little patience for applications that do not perform in auseful manner or require cumbersome registration procedures; i.e., auser may not wish to spend the time needed to set and personalize anapplication leading to a lower likelihood of the user using and/oradopting the application.

There exist applications and services that attempt to automatically fillin some of the user's personal information and preferences for anapplication or service. For example, an application or service mayattempt to provide an email address or home address so that the userneed not manually enter the data. However, each application may havedifferent fields, labels, types, or formats of data, making automaticcompletion of this information difficult. Furthermore, other informationthat is not directly inputted by the user may not be available for usein other applications.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the detaileddescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used in isolation as an aid in determining the scope of the claimedsubject matter.

In various embodiments, systems, methods, and computer-readable storagemedia are provided for automating personalized out-of-the-box (OOTB) orongoing in-application settings. For example, a user profile can bebuilt for a user containing collected and observed data for the user.The user profile can be stored in a profile data store on a user deviceor in cloud storage. When the user performs a triggering event, e.g.,installs a new application or service, settings can be automaticallypopulated from the user profile based on, e.g., a confidence level ofthe application or service. Thus, a user need not manually populatesettings for the application or service, and the application or servicewill be ready to use in a personalized manner from the start, allowingfor greater acceptance and trial of new applications and services.

Some embodiments include detecting a triggering event for a request orexchange of information between an information service and anapplication or service, determining a trust level and domain of theinformation for the application or service, identifying the informationto be shared with the application or service, and sharing theinformation with the application or service.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the disclosure are described in detail below with referenceto the attached drawing figures, wherein:

FIG. 1 is a block diagram of an example operating environment suitablefor implementations of the present disclosure;

FIG. 2 is a diagram depicting an example computing architecture suitablefor implementing aspects of the present disclosure;

FIGS. 3 and 4 depict flow diagrams of methods for automatingpersonalization of OOTB or ongoing in-application settings, inaccordance with embodiments of the present disclosure; and

FIG. 5 is a block diagram of an exemplary computing environment suitablefor use in implementing an embodiment of the present disclosure.

DETAILED DESCRIPTION

The subject matter of aspects of the present disclosure is describedwith specificity herein to meet statutory requirements. However, thedescription itself is not intended to limit the scope of this patent.Rather, the inventors have contemplated that the claimed subject mattermight also be embodied in other ways, to include different steps orcombinations of steps similar to the ones described in this document, inconjunction with other present or future technologies. Moreover,although the terms “step” and/or “block” may be used herein to connotedifferent elements of methods employed, the terms should not beinterpreted as implying any particular order among or between varioussteps herein disclosed unless and except when the order of individualsteps is explicitly described.

There exist conventional means for “auto-filling” fields and/or settingsof an application or service. For example, a system can store a name andaddress of a user (e.g., when the user enters their name and address forthe first time, the system can ask if the user would like to save theinformation). When an application or service on the system requests thename and address of a user, the system can automatically populate thosefields with the stored information. However, there are certainadvantages and disadvantages with the conventional means. For example,it may be difficult to enable interoperability or exchange ofinformation among applications and services, such as the sharing of usercontext and preferences, because these applications and services are nottypically designed to interoperate with each other. Furthermore,addressing this problem typically requires significant coordinationamong developers and publishers. So most of the time, users are unableto seamlessly share context or preferences between applications andservices, requiring the user to manually enter information for eachapplication or service. A user may find entering information for eachapplication or service to be burdensome, causing fewer applications andservices to be adopted by the user.

Accordingly, various aspects of the technology described herein aregenerally directed to systems, methods, and computer-readable storagemedia for automating personalization of OOTB or ongoing in-applicationsettings. By way of example and not limitation, a triggering event canbe detected for a request or exchange of information between aninformation service and an application or service, a trust level anddomain can be determined for the application or service, and theinformation to be shared with the application or service can beidentified. This information can then be shared with the application orservice.

In some embodiments, a platform and application programming interface(API) is provided for computer applications and services to store andretrieve context data, including data associated with the user. Forexample, the context data may include information related to a task,such as reading email, being carried out on a computing device used bythe user. It should be understood without limitation that context datacan be any data associated with a user, such as options, parameters, orother configurations associated with user experience, content,applications, services, or computing devices.

In some embodiments, the platform may be cloud based and the contextdata may be shared across client computing devices (sometimes referredto herein as “user devices”) over the Internet. For example, as will befurther described, the context data may be preserved in a cloud-baseddata store associated with the user. Using the API, applications andservices running on client devices with an Internet connection canaccess the data store, to store or retrieve the context data. Theplatform and API enable the sharing of the context data across nearlyany application or service that may be used for a particular task,including applications or services developed using different computerprogramming languages and/or operating on different types of userdevices, or user devices running different operating systems. Thus, forexample, user data can be collected from observed data the user providesto applications and services on the user device. This user data can formthe basis of settings stored at the data store. When a user performs atriggering event, such as installing a new application or service, thestored settings can be automatically sent to the application or service.As a result, the user need not enter the stored settings manually intothe application or service. In this way, embodiments of the presentdisclosure also facilitate interoperability and enable an application orservice to appear personalized from the start. It should be understoodthat settings generally refer to any data used by an application orservice to provide a personalized experience to the user. Thus, asetting can be an explicit setting where the user inputs values for afield, or can be inferred from some interaction with a user device, suchas when the user normally leaves for work each day. The settingsdescribed above are for illustrative purposes only, and many more typesof settings can be envisioned.

Access to the data store may be managed by a trust level and domaindeterminer, which enables a trust level and domain of information forthe application or service to be used to identify which storedinformation is to be sent to the application or service. Communicationto and from an application or service may be managed by an applicationinterface. For example, the application interface can analyze thecontext data for each user in order to determine inferences about theuser or usage patterns. The application interface may be used todetermine typical user preferences and access permissions associatedwith context data, which may be used to determine default settings. Insome instances, based on the inferences, settings can be automaticallyset for an improved computing experience.

In some embodiments, context data includes information related to a taskbeing carried out with a computing device used by a user (e.g., a userdevice) or other contextual information associated with a user sessionof a computer application, computing service, or user computing device.In some embodiments, context data may include information thatcorresponds to a state of a computing-device-provided experience, whichmay be associated with a user session of the application, service, oruser computing device. By way of example and without limitation, thecontext data associated with a task of playing a song, via amusic-playing application or service operating on a user device, mightinclude information about the song being played including a tracknumber, or title, or other song identifier; a source of the song (suchas a file path, online address, streaming music account, or similarinformation specifying a computer-accessible location of the song filesuch that the song may be potentially accessed by another application,service, or user device); previous song(s) played; number of times thissong has been listened to; a playlist of upcoming songs queued forplayback; offset information indicating the present location of the songas it is played; user playback settings, such as visualization settings;audio equalization configurations; headphone or speaker configurations;volume; communication network connection(s) information; other settings,options, parameters, configurations or user preferences related to thetask of playing or listening to music with the user device; informationabout user interactivity during the song playback, such as otherapplications and services accessed or websites browsed to, for example;or other contextual information associated with the user, the userdevice, or the playing of the song on the user device.

As previously described, access to the data store may be managed by atrust level and domain determiner based on a trust level and domain ofinformation for the application or service. Thus, by way of example andwithout limitation, access may be managed based on the publisher of theapplication or service; the particular application or service requestingaccess to context data; the type of application or service or otherproperty of the application or service; the type of data beingrequested; how the application or service will use the context data;time or date; the duration of time for which the application or servicehas been used; the number of previous accesses or requests to accesscontext data (or the rate of access or requests to access) by theapplication or service; the amount of context data that has previouslybeen shared with the application or service; a degree of confidence thatthe application or service is legitimately authorized to receive thecontext data (e.g., where a request appears suspicious, only a limitedamount of context data may be shared, such as context data that does notinclude sensitive or secure data about the user); or other propertiesassociated with or nearly any other criteria related to the applicationor service.

Turning now to FIG. 1, a block diagram is provided showing an exampleoperating environment 100 in which some embodiments of the presentdisclosure may be employed. It should be understood that this and otherarrangements described herein are set forth only as examples. Otherarrangements and elements (e.g., machines, interfaces, functions,orders, and groupings of functions) can be used in addition to orinstead of those shown, and some elements may be omitted altogether forthe sake of clarity. Further, many of the elements described herein arefunctional entities that may be implemented as discrete or distributedcomponents or in conjunction with other components, and in any suitablecombination and location. Various functions described herein as beingperformed by one or more entities may be carried out by hardware,firmware, and/or software. For instance, some functions may be carriedout by a processor executing instructions stored in memory.

Among other components not shown, example operating environment 100includes a number of user computing devices, such as user devices 102 aand 102 b through 102 n; a number of data sources, such as data sources104 a and 104 b through 104 n; server 106; sensors 103 a and 107; andnetwork 110. It should be understood that environment 100 shown in FIG.1 is an example of one suitable operating environment. Each of thecomponents shown in FIG. 1 may be implemented via any type of computingdevice, such as computing device 500 described in connection to FIG. 5,for example. These components may communicate with each other vianetwork 110, which may include, without limitation, one or more localarea networks (LANs) and/or wide area networks (WANs). In exemplaryimplementations, network 110 comprises the Internet and/or a cellularnetwork, amongst any of a variety of possible public and/or privatenetworks.

It should be understood that any number of user devices, servers, anddata sources may be employed within operating environment 100 within thescope of the present disclosure. Each may comprise a single device ormultiple devices cooperating in a distributed environment. For instance,server 106 may be provided via multiple devices arranged in adistributed environment that collectively provide the functionalitydescribed herein. Additionally, other components not shown may also beincluded within the distributed environment.

User devices 102 a and 102 b through 102 n can be client user devices onthe client-side of operating environment 100, while server 106 can be onthe server-side of operating environment 100. Server 106 can compriseserver-side software designed to work in conjunction with client-sidesoftware on user devices 102 a and 102 b through 102 n, so as toimplement any combination of the features and functionalities discussedin the present disclosure. This division of operating environment 100 isprovided to illustrate one example of a suitable environment, and thereis no requirement for each implementation that any combination of server106 and user devices 102 a and 102 b through 102 n remain as separateentities.

User devices 102 a and 102 b through 102 n may comprise any type ofcomputing device capable of use by a user. For example, in oneembodiment, user devices 102 a through 102 n may be the type ofcomputing device described in relation to FIG. 5 herein. By way ofexample and not limitation, a user device may be embodied as a personalcomputer (PC), a laptop computer, a mobile or mobile device, asmartphone, a tablet computer, a smart watch, a wearable computer, apersonal digital assistant (PDA) device, a music player or an MP3player, a global positioning system (GPS) or device, a video player, ahandheld communications device, a gaming device or system, anentertainment system, a vehicle computer system, an embedded systemcontroller, a camera, a remote control, a bar code scanner, acomputerized meter or measuring device, an appliance, a consumerelectronic device, a workstation, or any combination of these delineateddevices, a combination of these devices, or any other suitable computerdevice.

Data sources 104 a and 104 b through 104 n may comprise data sourcesand/or data systems, which are configured to make data available to anyof the various constituents of operating environment 100, or system 200described in connection to FIG. 2. (For instance, in one embodiment, oneor more data sources 104 a through 104 n provide (or make available foraccessing) user data to user-data collection component 210 of FIG. 2.)Data sources 104 a and 104 b through 104 n may be discrete from userdevices 102 a and 102 b through 102 n and server 106 or may beincorporated and/or integrated into at least one of those components. Inone embodiment, one or more of data sources 104 a through 104 n compriseone or more sensors, which may be integrated into or associated with oneor more of the user device(s) 102 a, 102 b, or 102 n or server 106.Examples of sensed user data made available by data sources 104 athrough 104 n are described further in connection to applicationinterface 220 of FIG. 2.

Operating environment 100 can be utilized to implement one or more ofthe components of system 200, described in FIG. 2, including componentsfor interfacing with applications and services on user devices,determining trust levels and domains for applications and services,identifying context data for settings, and storing user profiles.Operating environment 100 also can be utilized for implementing aspectsof methods 300 and 400 in FIGS. 3 and 4, respectively.

Referring now to FIG. 2, with FIG. 1, a block diagram is providedshowing aspects of an example computing system architecture suitable forimplementing an embodiment of the disclosure and designated generally assystem 200. System 200 represents only one example of a suitablecomputing system architecture. Other arrangements and elements can beused in addition to or instead of those shown, and some elements may beomitted altogether for the sake of clarity. Further, as with operatingenvironment 100, many of the elements described herein are functionalentities that may be implemented as discrete or distributed componentsor in conjunction with other components, and in any suitable combinationand location.

Example system 200 includes network 110, which is described inconnection to FIG. 1, and which communicatively couples components ofsystem 200 including user-data collection component 210, applicationinterface 220, trust level and domain determiner 230, storage 250, andone or more user device(s) 260. User-data collection component 210,application interface 220, trust level and domain determiner 230, andstorage 250 may be embodied as a set of compiled computer instructionsor functions, program modules, computer software services, or anarrangement of processes carried out on one or more computer systems,such as computing device 500 described in connection to FIG. 5, forexample.

In one embodiment, the functions performed by components of system 200are associated with one or more personal assistant applications,services, or routines. In particular, such applications, services, orroutines may operate on one or more user devices (such as user device102 a), servers (such as server 106), may be distributed across one ormore user devices and servers, or be implemented in the cloud. Moreover,in some embodiments, these components of system 200 (includingcomponents 210, 220, 230, and 250) may be distributed across a network,including one or more servers (such as server 106) and/or client devices(such as user device 102 a), in the cloud, or may reside on a userdevice, such as user device 102 a. Moreover, these components, functionsperformed by these components, or services carried out by thesecomponents may be implemented at appropriate abstraction layer(s), suchas the operating system layer, application layer, hardware layer, etc.,of the computing system(s). Alternatively, or in addition, thefunctionality of these components and/or the embodiments describedherein can be performed, at least in part, by one or more hardware logiccomponents. For example, and without limitation, illustrative types ofhardware logic components that can be used include Field-programmableGate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs),Application-specific Standard Products (ASSPs), System-on-a-chip systems(SOCs), Complex Programmable Logic Devices (CPLDs), etc. Additionally,although functionality is described herein with regards to specificcomponents shown in example system 200, it is contemplated that in someembodiments, functionality of these components can be shared ordistributed across other components.

User data may be received from a variety of sources where the data maybe available in a variety of formats. For example, in some embodiments,user data received via user-data collection component 210 may bedetermined via one or more sensors (such as sensors 103 a and 107 ofFIG. 1), which may be on or associated with one or more user devices(such as user device 102 a), servers (such as server 106), client userdevice(s) 260, and/or other computing devices. As used herein, a sensormay include a function, routine, component, or combination thereof forsensing, detecting, or otherwise obtaining information, such as userdata, from a data source 104 a, and may be embodied as hardware,software, or both. By way of example and not limitation, user data mayinclude data that is sensed or determined from one or more sensors(referred to herein as sensor data), such as location information ofmobile device(s), mobile-device data (such as device state, chargingdata, date/time, configurations or settings, or other informationderived from a mobile device), user-activity information (for example:app usage data; information regarding applications and services utilizedor tasks performed on a user device and related contextual informationsuch as usage time(s), files accessed, application configurations, andonline activity; searches; voice data such as automatic speechrecognition; activity logs; communications data including calls, texts,instant messages, and emails; website posts; other user data associatedwith communication events; other user interactions with a user device,etc.) including user activity that occurs over more than one userdevice, user history, session logs, application data, contacts data,calendar and schedule data, notification data, social network data, news(including popular or trending items on search engines or socialnetworks), online gaming data, ecommerce activity (including data fromonline accounts such as Microsoft®, Amazon.com®, Google®, eBay®,PayPal®, video-streaming services, gaming services, or Xbox Live®),user-account(s) data (which may include data from user preferences orsettings associated with a personalization-related (e.g., “personalassistant” or “virtual assistant”) application or service), home-sensordata, appliance data, global positioning system (GPS) data, vehiclesignal data, traffic data, weather data (including forecasts), wearabledevice data, other user device data (which may include device settings,profiles, network-related information (e.g., network name or ID, domaininformation, workgroup information, other network connection data, Wi-Finetwork data, or configuration data, data regarding the model number,firmware, or equipment, device pairings, such as where a user has amobile phone paired with a Bluetooth headset, for example, or othernetwork-related information)), gyroscope data, accelerometer data,payment or credit card usage data (which may include information from auser's PayPal account), purchase history data (such as information froma user's Xbox Live, Amazon.com or eBay account), other sensor data thatmay be sensed or otherwise detected by a sensor (or other detector)component(s) including data derived from a sensor component associatedwith the user (including location, motion, orientation, position,user-access, user-activity, network-access, user-device-charging, orother data that is capable of being provided by one or more sensorcomponents), data derived based on other data (for example, locationdata that can be derived from Wi-Fi, cellular network, or IP addressdata), and nearly any other source of data that may be sensed ordetermined as described herein.

User data, particularly in the form of contextual information, can bereceived by user-data collection component 210 from one or more sensorsand/or computing devices associated with a user. While it iscontemplated that the user data is processed, by the sensors or othercomponents not shown, for interpretability by user-data collectioncomponent 210, embodiments described herein do not limit the user datato processed data and may include raw data. In some respects, user datamay be provided in user-data streams or signals. A “user signal” can bea feed or stream of user data from a corresponding data source. Forinstance, a user signal could be from a smartphone, a home-sensordevice, a GPS device (e.g., for location coordinates), a vehicle-sensordevice, a wearable device, a user device, a gyroscope sensor, anaccelerometer sensor, a calendar service, an email account, a creditcard account, or other data source. In some embodiments, user-datacollection component 210 receives or accesses user-related datacontinuously, periodically, or as needed.

Example system 200 includes one or more client user device(s) 260.Client user device 260 may comprise a user computing device such ascomputing device 500 described in connection with FIG. 5, and may beembodied as a user device 102 a through 102 n described in FIG. 1. Someembodiments of this disclosure contemplate that client user device(s)260 may comprise a set of client user devices (e.g., 102 a through 102n) associated with a user, such as one or more mobile devices (e.g.,smartphone, tablet, laptop, etc.) used by the user, desktop computer,game/home-entertainment system, smart TV, vehicle computer system, smartthermostat, home-automation computing device, or other examples of userdevices 102 a through 102 n described in connection to FIG. 1.

As shown in example system 200, user client device 260 includesoperating system 261, local storage 265, one or more applications 262,services 264, context monitor 266, and API layer 268. It is contemplatedthat some client user devices 260 may include other components notshown, such as communication components, power-related components, orother hardware and/or software components typically found on usercomputing devices. Further, it will be understood that the components261, 265, 262, 264, 266, and 268 illustrated in FIG. 2 are exemplary innature and in number and should not be construed as limiting. Any numberof components may be employed to achieve the desired functionalitywithin the scope of embodiments hereof.

Operating system 261 comprises the system software that manages computerhardware or software resources of client user device 260 and providescommon services for computer programs such as applications 262, services264, context monitor 266, and API layer 268. Operating system 261 may bea single-task or multitask operating system. By way of example andwithout limitation, examples of operating systems 261 may includeMicrosoft Windows, Microsoft Windows Mobile, Google Android, GoogleChrome, Apple iOS, Apple OSX, Linux, Nokia Symbian, Blackberry OS, etc.Where example system 200 includes more than one client user devices 260,it is contemplated that in some embodiments, operating system 261 may bea different operating system for at least some of the client userdevices 260. For example, a set of client user devices associated with auser may include a smartphone running Google Android, an iPod touchrunning Apple iOS, and a laptop running Microsoft Windows 10.

Client user device 260 includes one or more applications 262 or services264. Applications 262 and services 264 comprise one or more computerprograms, software services, or routines that operate on client userdevice 260. In some embodiments, applications 262 or services 264 may bestand-alone computer programs that run on client user device 260 and aresupported by operating system 261. For example and without limitation,application 262 may comprise an app installed by the user, such as amusic-playing application, a video player, or a web browser. Someapplications 262 or services 264 may also be integrated into operatingsystem 261. For instance, services 264 may include services or routinesthat are built into the operating system, such as (without limitation)configurations, user preferences, communications services, userinterface services, or security settings.

In some embodiments, an application 262 or service 264 may be utilizedby a user to carry out or facilitate a task. For example, and withoutlimitation, an application 262 or service 264 may be used for checkingor reading email; other communication (e.g., instant messaging); playingmusic or video; reading or writing a document; browsing the Internet;browsing or engaging with a social media platform; navigation/geography;monitoring a weather forecast; calendar or scheduling; monitoring oraltering the user's environment such as adjusting lighting, heating orcooling the air, or reducing humidity; operating a vehicle or machine;or other applications, services, or tasks carried out for the user. Itis also contemplated that a client user device 260 may include more thanone application 262 or service 264 for handling a particular task, suchas more than one web browser or music player. Additionally, differentclient user devices 260 may include different applications 262 orservices 264 for handling tasks; for example, a smartphone client userdevice may include a native email application 262, and a laptop clientuser device may include a Microsoft Outlook email application 262. Insome instances, an application 262 or service 264 may have userpreferences, such as settings, which may be associated with carrying outa task or may be used for configuring the functionality of theapplication 262 or service 264.

Context monitor 266 is generally responsible for monitoring user dataand determining context data. For example, embodiments of contextmonitor 266 monitor user data received from user-data collectioncomponent 210, which may include data associated with a client userdevice 260 or related information including data associated with anapplication 262 or service 264 installed or running on a client device260, or other user data that may be used for facilitating determiningcontext data. As described previously, context data may include usercontext or user preferences associated with a computing experience.Thus, in some instances, context data may be associated with anapplication 262 or service 264 performing a task. The context data mayalso include other contextual information associated with a user sessionof application 262, service 264, or client user device 260. In someembodiments, context monitor 266 monitors or determines context data, asfurther described herein.

In some embodiments, context monitor 266 extracts context data and othercontextual information from user data received from user-data collectioncomponent 210. For example, context monitor 266 may receive user data,parse the data, in some instances, and identify and extract contextfeatures or variables. In some embodiments, context monitor 266 extractsinformation via screen scraping (or screen grabbing), keylogging,scanning memory, monitoring or analysis of operating system activity, orscanning communication(s). (Thus, in some embodiments, optical characterrecognition may be utilized. In some embodiments, semantic analysis maybe performed, which may use a semantic knowledge base.) In someembodiments, the context data features or variables are stored as arelated set of contextual information associated with a user session ortask being carried out via an application 262, service 264, or clientuser device 260. In some embodiments, application interface 220 maydetermine interpretive data from received user data. Interpretive datacorresponds to data utilized by these or other components (orsubcomponents) of system 200 to interpret user data. For example,interpretive data can be used to provide additional context to userdata. For example, in some embodiments, interpretive data comprisesstatistical data, inferences, or determinations made from raw user dataor other sensed user data. Moreover, it is contemplated that inembodiments, context monitor 266 or other components of system 200 mayuse user data and/or user data in combination with interpretive data forcarrying out the objectives of the subcomponents described herein.

As further described herein, the context data extracted or otherwisedetermined by context monitor 266 may be provided to a data store 250(or local storage 265 for embodiments implementing a peer-to-peerplatform), where it may be stored in context data 256 or a user profile255, to facilitate the sharing of the context data across applicationsand services. In some embodiments, context monitor 266 (or anotherservice of system 200, not shown) performs conflation on the contextdata. For example, overlapping information may be merged and duplicatedor redundant information eliminated.

In various embodiments, context monitor 266 may be embodied as acomponent on a client user device 260, as shown in example system 200,such as a stand-alone application or service, as part of a stand-aloneapplication or service, or as part of operating system 261.Alternatively or in addition, context monitor 266, or aspects thereof,may be incorporated into an application 262 or service 264. Contextmonitor 266 may also be embodied as a cloud-based service or as adistributed service that operates in the cloud and on one or more clientuser devices 260.

In some embodiments, context data may be identified by context monitor266 and stored continuously (e.g., as it changes during the first usersession); periodically; according to user settings, which may bespecified in user setting 258; based on a determined likelihood that theuser is about to (or has) started using another application 262 orservice 264; or as needed. In some embodiments, context data may includea date-time stamp (or value) indicating the time at which the contextdata was captured by context monitor 266. The date-time stamp may beused to determine the most recent context data, as well as an indicationof the staleness of the context data. The staleness may be useful wherea significant amount of time has passed between user sessions that sharethe context. In such a circumstance, it may be assumed that the contextmight have changed but was not preserved, and thus recreating thecontext from an older user session may not be desired.

In some embodiments, only the most recent context data is preserved incontext data 256. The context data may be stored in a user profileassociated with the user, such as in context data component 256 of userprofile 255 in storage 250. Alternatively or in additional, context datamay be stored locally on a client user device 260 in location storage265. Context monitor 266 may access API layer 268 to facilitateformatting, transferring, and/or storing or retrieving context data toor from a data store, such as context data 256 of user profile 255 instorage 250.

API layer 268 is generally responsible for connecting an application 262or service 264 on client user device 260 to a data store associated withthe user such as user profile 255 in storage 250 (or for facilitatingaccess by an application 262, service 264, or other component operatingon a client user device 260, such as context monitor 266, to contextdata 256 in the data store). The term access, as in accessing data, isused broadly herein and may include without limitation reading, writing,receiving, requesting, communicating, transferring, and/or other similaroperations. (In some embodiments, the level or degree of access to thecontext data 256 or other data in storage 250 (or local storage 265) iscontrolled by trust level and domain determiner 230, as furtherdescribed herein.)

In some embodiments, API layer 268 may facilitate formatting,requesting, communicating or transferring, and/or storing context datain the user's data store (e.g., in context data component 256 of userprofile 255). The context data may be determined by context monitor 266,as described previously. API layer 268 may receive context data to bestored in user profile 255 (e.g., the user's data store) from contextmonitor 266, such as may occur when user context or user preferences areto be preserved. API layer 268 may also or alternatively receive arequest for context data stored in the user profile 255 by contextmonitor 266 (or directly from an application 262 or service 264 onclient user device 260), such as may occur when settings are to beretrieved and loaded (or otherwise applied) to a new application 262 orservice 264).

In some embodiments, API layer 268 exposes a simple to use API on top ofcommon communication channels and protocols, such as RepresentationalState Transfer (REST) over HTTP(S), Simple Object Access Protocol(SOAP), or similar protocol. Data may be sent or received as JSON, CSV,RSS, XML, msgpack, Protocol Buffers, or other suitable data formats, forexample. In this way, API layer 268 may be accessible from nearly anyapplication 262 or service 264 (including context monitor 266) runningon top of an operating system 261 or platform on nearly any client userdevice 260, so long as Internet connectivity is available (or anothersuitable communication means, including, for example, direct orpeer-to-peer communication channels).

Application interface 220 communicates with an user device 260 todetermine which information an application or service is requesting andusing a stored user profile, which may be stored in a data storeassociated with the user, such as in user profile 256 stored incloud-based storage 250 (or in local storage 265, in some embodiments),to configure settings for the application or service. In someembodiments, application interface 220 can receive a list of thesettings (e.g., via the application metadata) to determine whichsettings the application or service is requesting information for. Insome embodiments, application interface 220 can communicate with theapplication or service to determine which settings the application orservice is requesting information for.

In some embodiments, the application interface can perform smartsemantic mapping between the user profile data and the received list ofsettings in the application or service. The smart semantic mapping caninclude: mapping the data, cropping the data, and reducing a level ofdetail of the data, among others. For example, if the user profileincludes data that the user has five children and their birth dates, thedata can be mapped to application data fields of parent (“yes”) andchildren under 5 years of age (“yes”). As another example, if the userprofile includes the user's address, the address can be split intostreet, city, state, and/or zip code fields of an application based onwhat fields are requested by the application or service.

Application interface 220 is generally responsible for controlling ormanaging access to the user's data (including context data). Applicationinterface 220 may be cloud-based or may be distributed across the cloud(or server side) and client-side or system 200. In the distributedembodiments, some aspects of application interface 220 may be performedby client user device(s) 260. As described previously, in someembodiments, application interface 220 may receive a request to access auser's information (for example a request to receive or update contextdata to the user's data store) from API layer 268. Furthermore, in someembodiments, application interface 220 may receive a request to populatesettings for an application or service from API layer 268. In responseto the request, application interface 220 may use the trust level anddomain determiner 230 associated with the user to determine theinformation to be shared with the application or service. At least someuser context data also may be configured to default settings or values,in some instances. Alternatively or in addition, some user context datamay be learned or inferred from the user or from other users (e.g.,through crowd sourcing, which may be facilitated using applicationinterface 220).

Trust level and domain determiner 230 is generally responsible fordetermining a confidence level for the application or service based on atrust level and domain of information for the application or service.For example, a confidence level can be used to determine whether toshare information with an application or service. If the confidencelevel is below a threshold, the information may not be shared requiringthe user to manually input settings into the application or service. Atrust level may be determined for the application 262 or service 264. Insome embodiments, different thresholds can be used to determine whichinformation to share with the application or service. For example, at abasic level, all non-sensitive information can be shared with theapplication or service. For more sensitive information (e.g., domain ofinformation), a higher confidence level may be required. For example, asocial security number may require that the application or service isfrom a trusted publisher and the social security number is required forsome function of the application or service. In some embodiments, if theconfidence level (e.g., trust level) is below a threshold, the trustlevel and domain determiner 230 can notify the user that the applicationor service is requesting information for which it is below the requiredconfidence level and prevent sharing of the information with theapplication or service.

Example system 200 also includes storage 250 and local storage 265.Storage 250 (and in some instances local storage 265) generally storesinformation including data, computer instructions (e.g., softwareprogram instructions, routines, or services), logic, profiles, and/orschemas used in embodiments described herein. In an embodiment, storage250 and/or local storage 265 comprises a data store (or computer datamemory). Further, although depicted as a single data store component,storage 250 may be embodied as one or more data stores and may includeaspects of local storage 265. As shown in example system 200, storage250 comprises a cloud-based data store, and local storage 265 comprisesa data store on a client user device 260.

Storage 250 includes one or more user profiles 255; an exampleembodiment of which is illustratively provided in FIG. 2. Example userprofile 255 includes information associated with a particular userincluding, among other things, context data 256, user devices 257, usersettings 258, and analytics data 259. In one embodiment, user profile255 may be associated with a Microsoft Account, Google Account (orGoogle Drive), Apple iCloud, or an online cloud-based storage account.Context data 256 is described above and may include user contextinformation, user preferences, and other contextual information. Thecontext data may correspond to a particular task or category of task,experience, or content, or a type of application, service, or device,and may be defined according to one or more schemas 230. In someembodiments, where context data 256 corresponds to a task or userexperience that includes content or media, context data 256 may includeinformation about the location or source of the content (e.g., anaddress or file path location) or may include a copy of the content ormedia (e.g., a video file or song file). In some embodiments, contextdata 256 may be stored securely with its access managed by accesscontrol manager 260.

User account(s) and activity data 257 generally includes user datacollected from user-data collection component 210 (which in some casesmay include crowd-sourced data that is relevant to the particular user),and may be used for accessing content corresponding to a task (e.g., auser's email account information and credentials enabling an emailmessage to be accessed, identified, and loaded into a second usersession), or may be used for determining context data about the user(e.g., user behavior patterns). User account(s) and activity data 246may include data associated with user accounts, such as online accounts(e.g. email, social media), Microsoft® Net passport, user data relatingto user accounts such as user emails, texts, instant messages, calls,and other communications; social network accounts and data, such as newsfeeds; online activity; and calendars, appointments, application data,or the like. Some embodiments of user account(s) and activity data 246may store information across one or more databases, knowledge graphs, ordata structures.

User settings 258 generally include user settings regarding userpreferences other than access parameters associated with a contextsharing system and services. For example, a user may specify a frequencyat which context is preserved. As another example, a user may specifywhether to preserve context based on properties of communicationsnetworks (e.g., a user may elect not to share context when the user isroaming and the user may incur expensive data charges).

Analytics data 259 generally includes personalized content forpresentation to the user, such as recommendations or suggestions. Insome embodiments, application interface 220 accesses context data (fromstorage 250) and analyzes it to determine useful analytics information.For example, based on this analysis, application interface 220 maydetermine inferences about the user and her usage patterns. Theseinferences may be used to provide a personalized computing experience toa user; for instance, by providing information for fields that are notdirectly stored in storage 250. The analytics data, which may includethe recommendations, suggestions, or other related information derivedfrom the analysis, may be stored in analytics data 259 of user profile255, in storage 250.

In some embodiments, application interface 220 analyzes context dataacross multiple users, while maintaining user privacy, and providesinferences based on an entire user population or subsets of similarusers (e.g., users that have characteristics in common with other users,such as users located the same region; users that use the sameapplication 252, service 254, or type of user device 250; user that havesimilar user preferences, carry out similar tasks, or view or listen tosimilar content).

With reference now to FIG. 3, a flow diagram is provided illustrating anexample method 300 for automating entry of personalized information forOOTB or ongoing in-application settings. In some embodiments, method 300may be carried out on a server such as server 106 described in FIG. 1.At a high level, method 300 includes collecting and observing contextualinformation associated with a user. The contextual information may becommunicated to a data store, such as a cloud-based data store, where itmay be stored in a user profile associated with the user. Personalizedinformation for OOTB or ongoing in-application settings may beautomatically entered using the contextual information.

Accordingly, at step 310, a user profile is built using collected andobserved data. Embodiments of step 310 monitor tasks performed by theuser. As described herein, the task may be carried out by an application262 or service 264 for a user; for instance, reading email, playingmusic, controlling a vehicle, etc. In some embodiments, one or moresensors on a user device, such as sensor 103 a, or associated with auser device or applications 262 or services 264 running on the userdevice, such as sensor 107, or more generally, user-data collectioncomponent 210, may provide sensor data including user data to a contextmonitor 266. Accordingly, in some embodiments, a context monitor 266monitors the sensor data (including user data).

At step 320, the user profile is stored. The user profile contains theuser settings and can be changed over time. Thus, as a user continues touse the application or service, additional context data can be collectedand the user profile can be updated creating a richer user profile.

At step 330, based on a triggering event, at least some of the storedcontext data is sent to the application or service, e.g., theapplication or service is autopopulated with the stored data. Forexample, a user may install a new application or service on theirdevice. Based on the trust level and domain of information, data fromthe user profile is identified and sent to the application or service(which is described in further detail with regard to FIG. 4). Theidentified data maps to the requested fields of the application orservice on the user device.

In some embodiments, there can be smart semantic mapping between thecontext data and the required fields of the application or service. Forexample, if the stored context data includes data that the user has fivechildren and the children's birth dates, the data can be mapped toapplication or service data fields such as whether the user is a parent(“yes”) and whether the user has children under a certain age (“yes”).It should be understood that the mapping of context data to requestedfields need not be one-to-one, and instead can be one-to-many or many toone. In some embodiments, the content data can be modified when mappedto the required data. For example, the smart semantic mapping betweenthe content data and the required data fields in an application orsetting may include: mapping context data to required fields, croppingthe context data for required fields, and reducing a levels of detail ofthe data for required fields.

Turning to FIG. 4, a flow diagram is provided illustrating one examplemethod 400 for automating entry of personalized information for OOTB orongoing in-application settings. In one embodiment, method 400 may becarried out as a cloud-based process or a distributed computing process,using one or more servers or other computing devices. Each block or stepof method 400, and other methods described herein, comprises a computingprocess that may be performed using any combination of hardware,firmware, and/or software. For instance, various functions may becarried out by a processor executing instructions stored in memory. Themethods may also be embodied as computer-usable instructions stored oncomputer storage media. The methods may be provided by a stand-aloneapplication, a service or hosted service (stand-alone or in combinationwith another hosted service), or a plug-in to another product, to name afew.

At step 410, a triggering event for the exchange of information betweenan information service and a requesting application or service isdetermined. Examples of a triggering event include a first installationof an application or service, a first launch of an application orservice, a new task, and an update to an application or service. Thetriggering event signals to the information service that a preconditionfor the exchange of information has been initialized. It should beunderstood that the foregoing examples of a triggering event are forillustration purposes only, and other triggering events can beenvisioned. The exchange of information can be from the informationservice to the application or service, from the application or serviceto the information service, or both. For example, while the informationservice provides settings to the application or service, it may alsocollect information from the application or service.

At step 420, a trust level and domain of the information for therequesting application or service is determined. For example, if therequesting application or service is published by a reputable source, atrust level for the application or service may be high. Alternatively,if the application or service is from an unreputable or unverifiedsource, the trust level for the application or service may be low. Thetrust levels can be the same for all applications and services for aparticular publisher or may be determined on a per application basis. Insome embodiments, the trust leveled is determined from a number ofdownloads, a number of installs, or a rating of the application orservice. The domain of information is the type of information requestedby the application or service. For example, the domain could be thesensitivity of the information. The less sensitive the information is,the lower the trust level needs to be to share the information. Thedomain could be the category of the information. For example, theapplication or service could request location data, calendarinformation, etc. The domain can be determined from a request forinformation from the application or service. For example, theapplication or service can have a registration page with variousinformation it needs to collect to register the user to the applicationor service. Alternatively, the system can scan the application orservice and determine which fields the application or service requiresfrom a user. In some embodiments, the configured the trust level of theapplication or service can be modified based on interactions of the userwith the application or service. Thus, as the user continues to use theapplication or service, information shared with the application orservice can increase providing a better user experience to the user. Insome embodiments, the trust level of the application or service can bemodified based on interactions of a group of users with the applicationor service.

At step 430, the information to be shared can be determined. In a simplescenario the application or service may only be requesting a username.Since this may be potentially non-sensitive information, the system islikely to be able to provide that information. If the requestinginformation is, e.g., a social security number, the determined trustlevel and domain may prevent the information from being sent to theapplication or service. In some embodiments, the user may be notifiedthat the application or service is requesting information for which theconfidence level is too low. In some embodiments, the stored contextinformation is matched with a high level of confidence requested fieldsof the application or service. For example, a taxonomy can be used todetermine how to provide values for fields. The taxonomy can map thestored user data to fields. The taxonomy can be stored for the userprofile or provided by the application or service. Thus, for example, ifthe application or service is requesting an address, and the userprofile contained longitude and latitude coordinates, the coordinatescan be converted to an address and vice versa.

In some embodiments, the user profile data is semantically mapped to therequested fields. For example, if the user profile data includes datathat the user has five children and the children's birth dates, the datacan be mapped to application or service data fields such as whether theuser is a parent (“yes”) and whether the user has children under acertain age (“yes”).

At step 440, the information is shared with the application or service.

Accordingly, various aspects of technology directed to systems andmethods for automating entry of personalized information for OOTB orongoing in-application settings are described. It is understood thatvarious features, sub-combinations, and modifications of the embodimentsdescribed herein are of utility and may be employed in other embodimentswithout reference to other features or sub-combinations. Moreover, theorder and sequences of steps shown in the example methods 300 and 400are not meant to limit the scope of the present disclosure in any way,and in fact, the steps may occur in a variety of different sequenceswithin embodiments hereof. Such variations and combinations thereof arealso contemplated to be within the scope of embodiments of thisdisclosure.

Having described various implementations, an exemplary computingenvironment suitable for implementing embodiments of the disclosure isnow described. With reference to FIG. 5, an exemplary computing deviceis provided and referred to generally as computing device 500. Thecomputing device 500 is but one example of a suitable computingenvironment and is not intended to suggest any limitation as to thescope of use or functionality of embodiments of the disclosure. Neithershould the computing device 500 be interpreted as having any dependencyor requirement relating to any one or combination of componentsillustrated.

Embodiments of the disclosure may be described in the general context ofcomputer code or machine-usable instructions, including computer-usableor computer-executable instructions, such as program modules, beingexecuted by a computer or other machine, such as a personal dataassistant, a smartphone, a tablet PC, or other handheld device.Generally, program modules, including routines, programs, objects,components, data structures, and the like, refer to code that performsparticular tasks or implements particular abstract data types.Embodiments of the disclosure may be practiced in a variety of systemconfigurations, including handheld devices, consumer electronics,general-purpose computers, more specialty computing devices, etc.Embodiments of the disclosure may also be practiced in distributedcomputing environments where tasks are performed by remote-processingdevices that are linked through a communications network. In adistributed computing environment, program modules may be located inboth local and remote computer storage media including memory storagedevices.

With reference to FIG. 5, computing device 500 includes a bus 510 thatdirectly or indirectly couples the following devices: memory 512, one ormore processors 514, one or more presentation components 516, one ormore input/output (I/O) ports 518, one or more I/O components 520, andan illustrative power supply 522. Bus 510 represents what may be one ormore busses (such as an address bus, data bus, or combination thereof).Although the various blocks of FIG. 5 are shown with lines for the sakeof clarity, in reality, these blocks represent logical, not necessarilyactual, components. For example, one may consider a presentationcomponent such as a display device to be an I/O component. Also,processors have memory. The inventors hereof recognize that such is thenature of the art and reiterate that the diagram of FIG. 5 is merelyillustrative of an exemplary computing device that can be used inconnection with one or more embodiments of the present disclosure.Distinction is not made between such categories as “workstation,”“server,” “laptop,” “handheld device,” etc., as all are contemplatedwithin the scope of FIG. 5 and with reference to “computing device.”

Computing device 500 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by computing device 500 and includes both volatile andnonvolatile, removable and non-removable media. By way of example, andnot limitation, computer-readable media may comprise computer storagemedia and communication media. Computer storage media includes bothvolatile and nonvolatile, removable and non-removable media implementedin any method or technology for storage of information such ascomputer-readable instructions, data structures, program modules, orother data. Computer storage media includes, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVDs) or other optical disk storage, magneticcassettes, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store thedesired information and which can be accessed by computing device 500.Computer storage media does not comprise signals per se. Communicationmedia typically embodies computer-readable instructions, datastructures, program modules, or other data in a modulated data signalsuch as a carrier wave or other transport mechanism and includes anyinformation delivery media. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media includes wired media, such as awired network or direct-wired connection, and wireless media, such asacoustic, RF, infrared, and other wireless media. Combinations of any ofthe above should also be included within the scope of computer-readablemedia.

Memory 512 includes computer storage media in the form of volatileand/or nonvolatile memory. The memory may be removable, non-removable,or a combination thereof. Exemplary hardware devices include solid-statememory, hard drives, optical-disc drives, etc. Computing device 500includes one or more processors 514 that read data from various entitiessuch as memory 512 or I/O components 520. Presentation component(s) 516presents data indications to a user or other device. Exemplarypresentation components include a display device, speaker, printingcomponent, vibrating component, and the like.

The I/O ports 518 allow computing device 500 to be logically coupled toother devices, including I/O components 520, some of which may be builtin. Illustrative components include a microphone, joystick, game pad,satellite dish, scanner, printer, wireless device, etc. The I/Ocomponents 520 may provide a natural user interface (NUI) that processesair gestures, voice, or other physiological inputs generated by a user.In some instances, inputs may be transmitted to an appropriate networkelement for further processing. An NUI may implement any combination ofspeech recognition, touch and stylus recognition, facial recognition,biometric recognition, gesture recognition both on screen and adjacentto the screen, air gestures, head and eye tracking, and touchrecognition associated with displays on the computing device 500. Thecomputing device 500 may be equipped with depth cameras, such asstereoscopic camera systems, infrared camera systems, RGB camerasystems, and combinations of these, for gesture detection andrecognition. Additionally, the computing device 500 may be equipped withaccelerometers or gyroscopes that enable detection of motion. The outputof the accelerometers or gyroscopes may be provided to the display ofthe computing device 500 to render immersive augmented reality orvirtual reality.

Some embodiments of computing device 500 may include one or moreradio(s) 524 (or similar wireless communication components). The radio524 transmits and receives radio or wireless communications. Thecomputing device 500 may be a wireless terminal adapted to receivecommunications and media over various wireless networks. Computingdevice 500 may communicate via wireless protocols, such as code divisionmultiple access (“CDMA”), global system for mobiles (“GSM”), or timedivision multiple access (“TDMA”), as well as others, to communicatewith other devices. The radio communications may be a short-rangeconnection, a long-range connection, or a combination of both ashort-range and a long-range wireless telecommunications connection.When we refer to “short” and “long” types of connections, we do not meanto refer to the spatial relation between two devices. Instead, we aregenerally referring to short range and long range as differentcategories, or types, of connections (i.e., a primary connection and asecondary connection). A short-range connection may include, by way ofexample and not limitation, a Wi-Fi® connection to a device (e.g.,mobile hotspot) that provides access to a wireless communicationsnetwork, such as a WLAN connection using the 802.11 protocol; aBluetooth connection to another computing device is a second example ofa short-range connection, or a near-field communication connection. Along-range connection may include a connection using, by way of exampleand not limitation, one or more of CDMA, GPRS, GSM, TDMA, and 802.16protocols.

Many different arrangements of the various components depicted, as wellas components not shown, are possible without departing from the scopeof the claims below. Embodiments of the disclosure have been describedwith the intent to be illustrative rather than restrictive. Alternativeembodiments will become apparent to readers of this disclosure after andbecause of reading it. Alternative means of implementing theaforementioned can be completed without departing from the scope of theclaims below. Certain features and sub-combinations are of utility andmay be employed without reference to other features and sub-combinationsand are contemplated within the scope of the claims.

Embodiment 1. A system comprising: an information service configured to:detect a triggering event for an exchange of information between theinformation service and one or more application or service; determine atrust level and domain of information of the one or more application orservice; based on the trust level and domain of information, identifyinformation to be shared with the one or more application or service;and share the identified information.

Embodiment 2. The system of embodiment 1, wherein the informationservice is further configured to semantically map the identifiedinformation to requested information from the one or more application orservice.

Embodiment 3. The system of embodiment 1, wherein the triggering eventis one or more of installation of the one or more application orservice, running the one or more application or service for a firsttime, accessing a particular feature of the one or more application orone or more application or service, updating the application, oruninstalling the one or more application or service.

Embodiment 4. The system of any of embodiments 1-2, wherein theinformation service is further configured to: indicate to a user thatthe one or more application or service is not trusted when the trustlevel is below a threshold; and prevent sharing of the identifiedinformation with the one or more application or service.

Embodiment 5. The system of any of embodiments 1-4, wherein theinformation service is further configured to modify the trust level ofthe one or more application or service based on interactions of a groupof users with the one or more application or service.

Embodiment 6. The system of any of embodiments 1-5, wherein theinformation service is further configured to: modify the trust level ofthe application based on interactions of a group of users with theapplication.

Embodiment 7. The system of any of embodiments 1-6, wherein the domainof information comprises a sensitivity of the information.

Embodiment 8. The system of any of embodiments 1-7, wherein the domainof information comprises a category of the information.

Embodiment 9. The system of any of embodiments 1-8, wherein theidentifying information to be shared comprises matching with a highlevel of confidence stored profile and context information withrequested fields of the one or more application or service.

Embodiment 10. A system comprising: one or more processors; and computerstorage memory having computer-executable instructions stored thereonwhich, when executed by the processor, implementing automatedpersonalized out-of-the-box and ongoing in-application settings,comprising: building a user profile from collected and observed data fora user; storing the user profile in a data store; and based on atriggering event, autopopulate one or more required fields of one ormore application or service with the stored user profile.

Embodiment 11. The system of embodiment 10, wherein a trust level anddomain of information of the one or more application or service is usedto determine which information from the user profile is used toautopopulate the one or more application or service.

Embodiment 12. The system of embodiment 10-11, wherein the collected andobserved data comprises data monitored from tasks performed by the user.

Embodiment 13. The system of embodiment 10-12, wherein the instructionsfurther comprise modifying the user profile based on interactions of theuser with the one or more application or service.

Embodiment 14. A computer-performed method for automating loading ofpersonalized out-of-the-box and ongoing in-application settings, themethod comprising: detecting a triggering event for a request ofinformation between an information service and one or more applicationor service; determining a trust level and domain of the information forthe one or more application or service; based on the trust level anddomain, determining information to be shared with the one or moreapplication or service; semantically mapping the determined informationto the requested information from the one or more application orservice; and sharing the semantically mapped information.

Embodiment 15. The method of embodiment 14, wherein the determining atrust level comprises determining an identity of a publisher of the oneor more application or service.

Embodiment 16. The method of any of embodiments 14-15, wherein thedetermining a trust level comprises determining a rating of the one ormore application or service.

Embodiment 17. The method of any of embodiments 14-16, wherein thedetermining a trust level comprises determining a number of downloadsand uninstalls of the one or more application or service.

Embodiment 18. The method of embodiment 14-17, wherein the determinedinformation comprises context information gathered for a user computingdevice.

Embodiment 19. The method of any of embodiments 14-18, the methodfurther comprising gathering context data from the one or moreapplication or service.

Embodiment 20. The method of any of embodiments 14-19, the methodfurther comprising gathering context data from the application fordifferent users of the one or more application or service; and whereinthe determined information comprises the gathered context data.

What is claimed is:
 1. A system comprising: one or more processors; andone or more computer storage hardware media storing computer-executableinstructions that are executed to implement a method comprising:detecting a triggering event that initiates an exchange of informationbetween an information service and an application or service;determining a trust level of the application or service and a domain ofinformation, wherein the trust level is modified based on userinteraction with the application or service and wherein the domain ofinformation comprises a category of information requested from theinformation service by the application or service; based on the trustlevel and the domain of information, identifying information to sharewith the application or service; semantically mapping the identifiedinformation to the requested information; and sharing the semanticallymapped information with the application or service.
 2. The system ofclaim 1, wherein the triggering event is one or more of installation ofthe application or service, running the application or service for afirst time, accessing a particular feature of the application orservice, updating the application or service, or uninstalling theapplication or service.
 3. The system of claim 1, wherein the methodfurther comprises: indicating to a user that the application or serviceis not trusted when the trust level is below a threshold; and preventingsharing of the identified information with the application or service.4. The system of claim 1, wherein the method further comprises modifyingthe trust level of the application or service based on interactions of agroup of users with the application or service.
 5. The system of claim1, wherein the domain of information comprises a sensitivity of theinformation.
 6. The system of claim 1, wherein the domain of informationcomprises at least one of location data or calendar information.
 7. Thesystem of claim 1, wherein identifying the information to sharecomprises matching with a high level of confidence stored profile andcontext information with requested fields of the application or service.8. A computer-performed method for automating loading of personalizedout-of-the-box and ongoing in-application settings, the methodcomprising: detecting a triggering event that initiates a request ofinformation between an information service and an application orservice; determining a trust level for the application or service and adomain of information, wherein the trust level is modified based on userinteraction with the application or service and wherein the domain ofinformation comprises a category of information requested from theinformation service by the application or service; based on the trustlevel and the domain of information, determining information to sharewith the application or service; semantically mapping the determinedinformation to the requested information; and sharing the semanticallymapped information with the application or service.
 9. The method ofclaim 8, wherein determining the trust level comprises determining anidentity of a publisher of the application or service.
 10. The method ofclaim 8, wherein determining the trust level comprises determining arating of the application or service.
 11. The method of claim 8, whereindetermining the trust level comprises determining a number of downloadsand uninstalls of the application or service.
 12. The method of claim 8,wherein the determined information comprises context informationgathered for a user computing device.
 13. The method of claim 8, furthercomprising gathering context data from the application or service. 14.The method of claim 8, further comprising gathering context data fromthe application or service for different users of the application orservice; and wherein the determined information comprises the gatheredcontext data.
 15. One or more computer storage hardware media storingcomputer-executable instructions that are executed by a computing deviceto implement a method comprising: detecting a triggering event thatinitiates an exchange of information between an information service andan application or service; determining a trust level for the applicationor service and a domain of information, wherein the trust level ismodified based on user interaction with the application or service andwherein the domain of information comprises a category of informationrequested from the information service by the application or service;based on the trust level and the domain of information, determininginformation to share with the application or service; semanticallymapping the determined information to the requested information; sharingthe semantically mapped information with the application or service. 16.The media of claim 15, wherein the triggering event comprisesinstallation of the application or service.
 17. The media of claim 15,wherein the semantically mapping comprises at least one of mapping thedetermined information, cropping the determined information, or reducinga level of detail of the determined information.
 18. The media of claim15, wherein the method further comprises preventing the exchange ofinformation between the information service and the application orservice when the trust level is below a threshold.
 19. The media ofclaim 15, wherein the trust level is determined based on an identity ofa publisher of the application or service.
 20. The media of claim 15,wherein the trust level is determined based on a rating of theapplication or service.